doc: add Helm chart deployment page for Kubernetes - #494

⚠️ important: the PR body already links #3218, so this is only about merge order. The chart is not on apache/hugegraph master yet: gh api repos/apache/hugegraph/contents/helm?ref=master returns 404, #3132 was closed without merging, and #3218 is still an open draft. If this PR merges first, the site publishes a guide where the helm install in 3.2 fails because helm/hugegraph does not exist on master, and all seven tree/master/helm/hugegraph links on the page (EN and CN) are 404s. Please convert this PR to draft until #3218 merges.

Still applies at 795d5f8. Checked 2026-10-02: apache/hugegraph master (176fb56dd) has no helm/ directory, and apache/hugegraph#3218 is open (out of draft, head d05741d9c). Until it merges, the install in 3.2 and the tree/master/helm/hugegraph links fail. Leaving this thread open as the merge-order gate: merge #3218 first, or hold this PR until then.

Still applies at a5fadcc. Checked 2026-10-03: apache/hugegraph master (02628ed50) has no helm/ directory, and apache/hugegraph#3218 is open at 2a6e2c404. Leaving this thread open as the merge-order gate: merge #3218 first, then this PR.

Minor: this section lists two kinds of state that survive uninstall, but there is a third. With hubble.enabled=true and hubble.persistence.enabled=true, templates/hubble-pvc.yaml at chart 2a6e2c404 annotates the Hubble PVC with helm.sh/resource-policy: keep, and its comment says the volume holds the stored connection metadata and credentials. An operator who follows this page and deletes only the StatefulSet PVCs leaves that volume, with its credentials, in the namespace. Please add the Hubble PVC here (for example: "With Hubble persistence on, its PVC is kept too; delete it to discard Hubble's stored connections and credentials") and make the same change in CN section 8, line 261.

⚠️ Important: The 20 s period and three failures describe detection in about one minute, but the chart sets store.terminationGracePeriodSeconds to 300 s. Kubelet can wait through that grace period before forcing down an unresponsive Store, so the total restart and recovery window can be several minutes longer. Please call one minute the approximate detection time and mention the grace period; sync the Chinese page.

⚠️ Important: This procedure tells operators to delete Store Pods one at a time, then says the PDB refuses a second eviction. If operators use ordinary Pod deletion, Kubernetes bypasses PDB enforcement; only Eviction API requests honor the budget. The PDB therefore cannot protect the manual rollout as written. Please specify an eviction-based procedure or limit this claim to kubectl drain and other eviction clients; sync Chinese. Kubernetes documentation.

⚠️ Important: Full shard-group membership and HTTP 200 from this endpoint do not prove the replacement has caught up. PartitionEngine.syncShardIdentities() updates the shard IDs in PD before waitForReplicate() completes, and this endpoint exposes the current logIndex during that wait. Please compare the replacement's index with the leader or a current peer for every group before deleting the old Tombstone record; sync Chinese.

⚠️ Important: PD returns this advertised URL to Hubble, which then sends Server login credentials to the discovered URL. This section allows http:// without the HTTPS or trusted-channel warning given for server.direct_url above. Please require HTTPS or a trusted private transport for production advertised URLs and sync Chinese.

⚠️ Important: This PD-mode example omits Hubble's PD REST credentials. operations.pd.password defaults to empty, while the chart's default PD REST authentication requires credentials; chart-managed Hubble injects operations.pd.username=hubble and the PD secret. As written, the external Hubble operations collector gets authentication failures. Add these properties to the example and show how to provide the PD credential securely; sync Chinese.

‼️ critical. Blocking: yes. Summary: This gate counts every shard entry, so a Leader+Follower+Learner group satisfies the full-count/one-Leader condition before the new replica is promoted; deleting another Store can leave only one voter. Please require one Leader and only Followers (no Learner/None) before continuing, including the shrink gate, and sync the Chinese instructions. Evidence: PartitionEngine adds peers as Learners and promotes them only after waitForReplicate; PD treats Learner as migration in progress.

⚠️ important. Blocking: no. Summary: The statement that the release admits only its own traffic holds only when no other applicable NetworkPolicy allows traffic to these Pods; Kubernetes unions allowed rules, so a broader policy can admit sources omitted from extraIngress. Please qualify this boundary and advise operators to audit other policies selecting these Pods in both languages. Evidence: Kubernetes documents additive NetworkPolicy rules and the union of allowed connections.

⚠️ important. Blocking: no. Summary: Rotating only through the Server auth API leaves the chart admin Secret unchanged, so the documented password lookup and helm test hook keep using the old credential. Please set the Secret to the API value and roll Server replicas to refresh their auth caches, or link to the chart README rotation procedure; sync Chinese. Evidence: The test hook reads PASSWORD from the chart Secret; the chart README requires Secret synchronization and a Server rollout.

⚠️ important. Blocking: no. Summary: Tombstoning a Store starts a separate 30-minute cooldown: balancePartitionShard() returns null during that interval, even after the documented 180-second patrol window. Please document the Tombstone cooldown before advising balancePartitions, and distinguish it from the BALANCE_SHARD_KEY timer. Evidence: The status listener records Tombstone time; the cooldown constant and early return and the 30-minute guard.

Important: Step 3 cannot succeed on a cluster this chart deployed. The chart sets HG_PD_INITIAL_STORE_COUNT to store.replicas (pd-statefulset.yaml L123-124), and that value is PD's minStoreCount (PDConfig L63-64). POST /v1/store/<id> goes through PDRestService.updateStore into StoreNodeService.updateStore, which refuses a Tombstone for a Store whose last state is Up when getStores().size() - 1 < minStoreCount (StoreNodeService L271-278). On a fresh 5-Store install, retiring a healthy Store gives 5 - 1 < 5, so PD returns LESS_ACTIVE_STORE ("The number of active stores is less then 5"). StoreAPI.setStore serializes that exception into the JSON body instead of failing the request, so an operator following the steps may not notice. Step 4 then never finishes. The Disaster Recovery retirement passes this check only because the replacement adds a second record at the same address. I traced this in the source at apache/hugegraph master 8fd9841eb and did not run it on a cluster. Please say that PD refuses to Tombstone an Up Store while the chart pins pd.initial-store-count to the current store.replicas. Then either document a path that works or mark Store shrink as unsupported for now, as the page already does for PD. Please make the same change in the Chinese page, section 8 step 3 (line 297).

Minor: This section and the deployment page treat Store growth as a plain values change, but three things about it go undocumented. (1) With the default store.pdb.minAvailable: 2, --set store.replicas=5 fails to render with "store.pdb.minAvailable must be at least store.replicas - 1" (_helpers.tpl L780-781); store.pdb.minAvailable has to move with the replica count in both directions, which also affects the helm upgrade in step 5 of the shrink below. (2) HG_PD_INITIAL_STORE_LIST and HG_PD_INITIAL_STORE_COUNT live in the PD Pod template, so growing Store rolls every PD Pod. A helm template diff of store.replicas 3 against 5 shows only those two PD env values changing. (3) PD schedules no balance task (TaskScheduleService.init), so new Stores hold no partitions until balancePartitions runs on the PD leader. Please add a short "Store, growing" paragraph that covers these three points and then the check from section 6 (full shard count, one Leader). Please sync the Chinese page, section 8 (line 283).